Digital identities and profiles of parties are becoming more and more relevant for enabling Internet transactions and interactions among citizens, service providers, enterprises and government institutions. For example, in an e-commerce scenario, a person initially provides their digital identity and profile information to an e-commerce site in order to access their services. After the user logs in and interacts with these services: it might happen that interaction with other web sites or organisations is needed to carry out a service. The user might be conscious of this or this might take place behind the scene, for example due to fact that the e-commerce site interacts with partners and suppliers. The e-commerce sites may or may not have prior agreements with these third parties or may or may not belong to the same web of trust.
In general users have little understanding or knowledge of the privacy laws and legislation that regulate the management of their information. The privacy and data protection laws that regulate this area are hard to enforce or monitor, especially when private information is spread across organisations and national boundaries. People perceive and address the related security and privacy issues in different ways, ranging from completely ignoring them (and indiscriminately disclosing their personal data), to being so concerned as to refrain from using any Internet applications. It is also frequently the case that users do not bother to read long lists of terms and conditions concerning privacy and confidentiality because they cannot understand them or do not have the time to do so. Thus, whilst users are often asked to grant authority to web sites to electronically manage their information, in many cases the user doesn't consider the implications of such a request and simply chooses the easiest way forward to obtaining the service they want.
Little has been done so far to allow the explicit management and enforcement of privacy policies by directly involving users (or entities acting on their behalf) especially in a context of multiparty interactions. Users have a lack of control over their personal information, especially after its initial disclosure. In addition, third parties (such as delegates, e-commerce sites or enterprises) have lack of control over the confidential information they manage on behalf of their customers, in particular when they disclose it to external entities, during transactions or interactions.
Privacy management solutions can play a key role in protecting identities and profiles, enforcing good management practices and helping to detect criminal activities and support forensic analysis. However, for such solution to succeed, they need to simplify users' experience so that people can feel they are in control of their personal data and that this data is managed in an accountable way. If people are not willing to be involved in the active protection and management of their digital assets, trusted third parties could do this on their behalf and could provide people with easy-to-use tools to monitor and keep the situation under control.
Mechanisms such as proposed by W3C allow users to define simple privacy policies but this is only meaningful for point-to-point interactions (see: “The Platform for privacy preferences 1.0 specification (P3P 1.0).” http://www.w3.org/tr/p3p—W3C Proposed Recommendation—2002)
Solutions based on federated identity management have also been implemented (such as Microsoft Passport) but, at least currently, rely on a closed web of trust. Identity providers must be part of trusted clubs and be compliant with predefined privacy policies. This approach limits scalability and flexibility of the allowed interactions and transactions.
A more fine-grained control over the privacy of personal data has been described in the papers:                G. karjoth, M. Hunter—A Privacy Policy Model for Enterprises, IBM Research, Zurich—15th IEEE Computer Foundations Workshop—June 2002        G. karjoth, M. Schunter, M. Waidner—Platform for Enterprise Privacy Practices: Privacy-enabled Management of Customer Data—2nd Workshop on Privacy Enhancing Technologies, Lecture Notes in Computer Science, Springer Verlang—2002        
In the first of these papers the authors define a privacy control language that includes user consent, obligations and distributed administration. In the second paper, the authors describe a platform for enterprise privacy practices (E-P3P) and introduce the “sticky policy” paradigm and mechanisms for enterprise privacy enforcement. Sticky policies are policies that are strictly associated with a user's data and drive access control decisions and privacy enforcement. The papers do not, however, describe how the strong associations between policies and confidential data are enforced, especially across enterprise boundaries. Users still need to trust the enterprise when disclosing their data. Leakage of personal and confidential information might happen, despite data protection laws and privacy policies, because of lack of security, dishonesty of some of the involved intermediaries and the complexity of the overall systems.
Furthermore, many of the current privacy mechanisms introduce an overhead in terms of usage of digital certificates at the user site (where data is encrypted) and complexity when dealing with dynamic metadata (policies) associated with the encrypted data
It is an object of the present invention to provide an improved way of effecting privacy management for personal data.
The present invention is in part based on the appreciation that Identifier-Based Encryption (IBE) has certain properties than can be adapted for use in privacy management.
Identifier-Based Encryption (IBE) is an emerging cryptographic schema. In this schema (see FIG. 1 of the accompanying drawings), a data provider 10 encrypts payload data 13 using both an encryption key string 14, and public data 15 provided by a trusted authority 12. This public data 15 is derived by the trusted authority 12 using private data 17 and a one-way function 18. The data provider 10 then provides the encrypted payload data <13> to a recipient 11 who decrypts it, or has it decrypted, using a decryption key computed by the trusted authority 12 in dependence on the encryption key string and its own private data.
A feature of identifier-based encryption is that because the decryption key is generated from the encryption key string, its generation can be postponed until needed for decryption.
Another feature of identifier-based encryption is that the encryption key string is cryptographically unconstrained and can be any kind of string, that is, any ordered series of bits whether derived from a character string, a serialized image bit map, a digitized sound signal, or any other data source. The string may be made up of more than one component and may be formed by data already subject to upstream processing. In order to avoid cryptographic attacks based on judicious selection of a key string to reveal information about the encryption process, as part of the encryption process the encryption key string is passed through a one-way function (typically some sort of hash function) thereby making it impossible to choose a cryptographically-prejudicial encryption key string. In applications where defence against such attacks is not important, it would be possible to omit this processing of the string.
Typically, the encryption key string serves to “identify” the intended message recipient and the trusted authority is arranged to provide the decryption key only to this identified intended recipient. This has given rise to the use of the label “identifier-based” or “identity-based” generally for cryptographic methods of the type under discussion. However, as will be seen hereinafter, the string may serve a different purpose to that of identifying the intended recipient. Accordingly, the use of the term “identifier-based” or “IBE” herein in relation to cryptographic methods and systems is to be understood simply as implying that the methods and systems are based on the use of a cryptographically unconstrained string whether or not the string serves to identify the intended recipient. Generally, in the present specification, the term “encryption key string” or “EKS” is used rather than “identity string” or “identifier string”; the term “encryption key string” may also used in the shortened form “encryption key” for reasons of brevity.
A number of IBE algorithms are known and FIG. 2 indicates, for three such algorithms, the following features, namely:                the form of the encryption parameters 5 used, that is, the encryption key string and the public data of the trusted authority (TA);        the conversion process 6 applied to the encryption key string to prevent attacks based on judicious selection of this string;        the primary encryption computation 7 effected;        the form of the encrypted output 8.        
The three prior art IBE algorithms to which FIG. 2 relates are:                Quadratic Residuosity (QR) method as described in the paper: C. Cocks, “An identity based encryption scheme based on quadratic residues”, Proceedings of the 8th IMA International Conference on Cryptography and Coding, LNCS 2260, pp 360-363, Springer-Verlag, 2001. A brief description of this form of IBE is given hereinafter.        Bilinear Mappings p using, for example, a modified Tate pairing t or modified Weil pairing e for which:p: G1×G1→G2 where G1 and G2 denote two algebraic groups of prime order q and G2 is a subgroup of a multiplicative group of a finite field. For the Tate pairing an asymmetric form is also possible:p: G1×G0→G2 where G0 is a further algebraic group the elements of which are not restricted to being of order q. Generally, the elements of the groups G0 and G1 are points on an elliptic curve though this is not necessarily the case. A description of this form of IBE method, using modified Weil pairings is given in the paper: D. Boneh, M. Franklin—“Identity-based Encryption from the Weil Pairing” in Advances in Cryptology—CRYPTO 2001, LNCS 2139, pp. 213-229, Springer-Verlag, 2001.        RSA-Based methods The RSA public key cryptographic method is well known and in its basic form is a two-party method in which a first party generates a public/private key pair and a second party uses the first party's public key to encrypt messages for sending to the first party, the latter then using its private key to decrypt the messages. A variant of the basic RSA method, known as “mediated RSA”, requires the involvement of a security mediator in order for a message recipient to be able to decrypt an encrypted message. An IBE method based on mediated RSA is described in the paper “Identity based encryption using mediated RSA”, D. Boneh, X. Ding and G. Tsudik, 3rd Workshop on Information Security Application, Jeju Island, Korea, August, 2002.        
In all of the above cases, the decryption key is generated by a trusted authority in dependence on the encryption key string.
A more detailed description of the QR method is given below with reference to the entities depicted in FIG. 1 and using the same notation as given for this method in FIG. 2. In the QR method, the trust authority's public data 15 comprises a value N that is a product of two random prime numbers p and q, where the values of p and q are the private data 17 of the trust authority 12. The values of p and q should ideally be in the range of 2511 and 2512 and should both satisfy the equation: p, q≡3 mod 4. However, p and q must not have the same value. Also provided is a hash function # which when applied to a string returns a value in the range 0 to N−1.
Each bit of the user's payload data 13 is then encrypted as follows:                The data provider 10 generates random numbers t+ (where t+ is an integer in the range [0, 2N]) until a value of t+ is found that satisfies the equation jacobi(t+,N)=m′, where m′ has a value of −1 or 1 depending on whether the corresponding bit of the user's data is 0 or 1 respectively. (As is well known, the jacobi function is such that where x2≡#modN the jacobi (#, N)=−1 if x does not exist, and=1 if x does exist). The data provider 10 then computes the value:s+≡(t++K/t+)modN where: s+ corresponds to the encrypted value of the bit m′ concerned, andK=#(encryption key string)        Since K may be non-square, the data provider additionally generates additional random numbers t (integers in the range [0, 2N)) until one is found that satisfies the equation jacobi(t−,N)=m′. The data provider 10 then computes the value:s−≡(t−−K/t−)modN as the encrypted value of the bit m concerned.        
The encrypted values s+ and s− for each bit m′ of the user's data are then made available to the intended recipient 11, for example via e-mail or by being placed in an electronic public area; the identity of the trust authority 12 and the encryption key string 14 will generally also be made available in the same way.
The encryption key string 14 is passed to the trust authority 12 by any suitable means; for example, the recipient 11 may pass it to the trust authority or some other route is used—indeed, the trust authority may have initially provided the encryption key string. The trust authority 12 determines the associated private key B by solving the equation:B2≡K modN (“positive” solution)
If a value of B does not exist, then there is a value of B that is satisfied by the equation:B2≡−K modN (“negative” solution)
As N is a product of two prime numbers p, q it would be extremely difficult for any one to calculate the decryption key B with only knowledge of the encryption key string and N. However, as the trust authority 12 has knowledge of p and q (i.e. two prime numbers) it is relatively straightforward for the trust authority 12 to calculate B.
Any change to the encryption key string 14 will result in a decryption key 16 that will not decrypt the payload data 13 correctly. Therefore, the intended recipient 11 cannot alter the encryption key string before supplying it to the trust authority 12.
The trust authority 12 sends the decryption key to the data recipient 11 along with an indication of whether this is the “positive” or “negative” solution for B.
If the “positive” solution for the decryption key has been provided, the recipient 11 can now recover each bit m′ of the payload data 13 using:m′=jacobi(s++2B,N)
If the “negative” solution for the decryption key B has been provided, the recipient 11 recovers each bit m′ using:m′=jacobi(s−+2B,N)